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A COMPUTER SYSTEM WITH TWO HEAPS IN CONTIGUOUS STORAGE 
Field of Che invencion 

The invention relates to a computer system suppoarting an 
olajecc-orienneci environment: Having acorage, ac least a pornion of which is 
divided into multiple heaps. 

Background of rhe Invention 

Programs written in the Java programming language (Java is a 
trademark of Sun Microsystems Inc) are generally run in a virtual machine 
environment, racher cnan airecriy on naraware . xnus a Java program is 
typically compiled into byte-code form, and then interpreted by a Java 
virtual machine iJVM) into hardware commands for the platform on which the 
JVM is executing. The JVM itself is an application running on the 
underlying op^r-^iting ^:yf?tem. Axx impoartant a.dvajitag-e o£ this: approach i» 

that Java applic.-xtions can run on a very wide range of platforms, providing 
of course that a JVM is available for each platform, 

Java is an object-oriented language. Thus a Java program is formed 
from a GCt o£ clacc filee Inaving methods that represent seqoiences o£ 
instructions (somewhat akin to subroutines) . A hierarchy of classes can be 
defined, with each class inheriting properties (including methods) from 
those classes which are above it in the nierarcny. For any given class in 
the hierarchy, its descendantc (i.Q- below it) are call subclasses, whilst 
its ajacestors (i.e. above it) arc called superclasses. At run- time objects 
are created as instantiations of these class files, and indeed the class 
files themselves are effectively loaded objects. One Java object can 

call a method in another Java object. In recent years Java has become very 
popular, and is described in many books, for exaovDle "Escploring Java" by 
Niemeyer and Peck, O'Reilly & Associates, 1996, USA, and "The Java Virtual 
Machine Specification" by Lindholm and Yellin. Addison-wedley, 1997, USA, 

The standard JVM architecture is generally designed to run only a 
single application, although, ciiis can t)c multi-threaded. In a server 
environment used for database transactions and such- like, each transaction 

ic t>-pically performed as a separate application, arather tKan ac different 
threads within an application. This is to ensure that every transaction 
starts with the JVM in a clean state. In other words, a new JVM is started 
for eacn transaction (i.e. for each new Java application) . Unfortunately 
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however this results in an initial delay in mnning Che application (the 
reasons for this will be desciribea irx mor* detail lateir) . The overhead d\ie 
CO chis frequent starting and then stopping a JVM as successive 
transactions are processed is significant, cind seriously degrades the 
scalability of Java server solutions. 

Various attentpts have been made to mitigate this problem. BP -562 6 60 -A 
describes a process whereby one JVM can fork into a parent and a child 
process, this being quicker than setting up a fresh JVlvi, The ability to 
run multiple processes in a Java-like system, thereby reducing overhead 
per application, is described in ^^Processes in KaffeOS; Isolation. Resource 
Management, and Sharing in Java" by G back, W Hsieh, and J Lepreau (see: 
http: / /www. cs .Utah, edu/flux/papers/kaffeos-osdiOO /main. html) . 

Another approach is described in "Oracle JServer Scalability and 
Performance" by Jeremy Litzt. July 1999 (see: 

http ; v^rww, oracle . com/Oatabase/documents/j server_scalability__ana_joerf ormance_ 
tv;p.pdf) . The JServer product available from Oracle CoTrporation, USA, 
supports the concept of multiple cessions (a session effectively 
representing a transaction or application) , each session including a . 
JServer session. R.esourcee such as re:^di-only bytecod© information are 
snared between the various sessions, but each individual session appears to 
its JServer client to be a dedicated conventional JVM. 

US patent application 09/3041^0, filed 30 April 99 ("A long Running 
Reusable Extendible Virtual Machine"), assigned to IBM Corporation (IBM 
docket YOR9-1999-0170) , discloses a virtual machine <VM) having two types 
of heap, a private heap and a shared hea.p . Th<s former is intended primarily 
ror storing application classes, whilst the latter is intended primarily 
for storing system classes and, as its name irttplies, is accessible to 
multiple VMa- A related idea is described in "Building a Java virtual 
machine for server applications: the JVM on OS/390^' by Diilenberger et al , 
IBM Systems iJou^nAl , Vol 39/l, J^inusiry 2000. Again chic implementation uses 
a shared heap to share system and potentially application classes for reuse 
by multiple workers, with each worker jVM also maintaining- a private or 
local heap to store data private to that particular jvm process. 

Th« Above documents are focueed primarily on the ability to easily 
run multiple JVMs in parallel. A different (and potentially complementary) 
approach is based on a serial rather than parallel configuration. Thus it 
is desircLble to run repeated transactions (i.e. applications) on the same 
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JVM^ since this could avoid having to reload all the system classes at the 
start of each application. However, one difficulty with thi<= is that each 
Application expect:* to run on a . fresh, clean, JVM. mere is a danger with 
serial re-use of a JVM that the state left from a previous transaction 
5 somehow influences the outcom© of a. new transaction. This unpredicnabilicy 

Is unacceptable in most circumstances. 

us pacenc application 09/584641 filed 31 May 2000 in the name of IBM 
Corporation (IBM docket number GB9-2000-0061) discloses an approach for 

10 px*oviding a OTVM with a reset capability. US provisional application 

60/208268 also filed 31 May 2000 in the name of IBM Corporation (IBM docket 
number YOR9-2000-0359) discloses Lhe idea of having two heaps in a JVM, One 
of chese is a transient heap, which is used to store trajisaction objects 
that will not persist into the next transaction, whilst a second heap is 

15 used for storing objects, such as system -r.bjects, that will persist. This 

approach provides Che basis for an efficient reset mechanism by simply 
deleting tbe transient heap. The techniques described herein represent 
optimisations of the above methods, to allow the JVM reset to be performed 
as cjuickly and consistently as: possible. 



20 



Summary o£ the Invention 



Accordingly the invention provides a computer system providing an 
obj ect-based environment , saicl computer system including storage , a 
25 contiguous linear portion of which is logically divided into first and 

second heaps located at opposite ends of the storage portion, with any gap 
between the two heaps representing an unallocated region of storage, 
wherein references are permitted from objects on the first heap to objects 
on the second Heap and vice versa, said system comprising; 
30 a garbage collector for operating across both heaps to remove objects 

that are no longer live; 

means for expanding the first heap into said unallocated region 
according to a first expansion policy; and 

means for expanaing the second heap into said unallocated region 

3 5 according to a second expansion policy. 

In a preferred etnbodiment , the computer system supports a transaction 
processing environment. The first heap is used for storing objects that are 
deleted at the end of tne current transaction (and so can be regarded as a 

4 0 transient heap) , and the second heap is used for storing objects that 

persist from one transaction to another. Since it is desired ror each 
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transaction co see as much as possible the same underlying system, the 
first heap is reset to the same predetermined initial size at the start of 
each. cr-;»jrx*?acr.ion - an eraror condition is irecumed i£ the second heap hac 
expanded such that it is not possible to reset the first heap to its 
predetermined initial size . 

In the preferred embodiment, a midpoint ie defined halfway between 
the first heap and second heap, when they each have theiir xnitiail size (ie 
in Che middle of the initially lanallocated region) . The first expansion 
policy is always to expand into tH«i unallocated region in. order to satisfy 
a storage request, whilst the second expansion policy is to expand into 
said unallocated region in order to satisfy a storage request until said 
midpoint is reached, whereupon said syscem pret erent ially performs a 
garbage collection to satisfy said request. Thus the first heap is 
generally freer to expand than the second heap. The reason for this is that 
the space will be reclaimed from the first heap at the end of the 
transaction, but this is not necessarily the case for th« second heap. 
Nevertheless, nne rate of expansion of the first heap into rhe unallocated 
region is slower once Che first heap has passed said midpoint, in order to 

try CO beet conserve limited resources. 

In the pref iorr^d embodiment , the c«cond orcpansion policy further 
includes trying to shrink the first heap to allow room to expand said 
second heap in order to satisfy a storage request, in other words?, if che 
first heap does not actually occupy all its allocated space, then it may be 
possible to transfer this to the second heap. This helps to optimize the 
ujse of storage between the two hccips . 

Also in the preferred embodiment, the garbage collector optionally 
performs a compact operation after a garbage collection of che first and 
second heaps . The compact operation is perf oirmed in tbs^otisb to a first sec 
of criteria relevant: co che first heap^ and a second set of criteria 
relevamt to the second heap. Various complex compaction policies can be 
Adopted, b-ut generally it io preferred that the second act o£ criteria, arc 
more sensitive to fragmentation than the first set of criteria. The reason 
for this is that the first heap can be deleted at che end of a tr-ansra-ction., 
2md so its level of f ragmencacion is less of a concern than for the second 
heap which will persist for future transactions. It is preferred that after 
a compact operation^ the firct and second heaps are shrunk i£ posssible, 
thereby returning released storage to said unallocated region. This helps 
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to ensure chat free space is avail£Lble for future storage reouests on 
either heap. 

Although a single garbage collector is used for- both heaps, the 
trigrgei: for gar-bagc collection and the type of garbage collection performed 
can vary between the first and second heaps, such as in accordance with 
their respective eacpansion policies. Thic allows the garbage collection 
strategy to be tuned to the requirements of each individual heap. This 
idea can be extended to only performing garbage collection on one heap at a 
timo. For example, ±11 a transaction is nearly finished, but more space is 
needed on the second heap, then it may not be necessary to al*?o garbage 
collect the first heap, since this will soon be deleted. Likewise 
different garbage collection techniques (such as mark- sweep and copy 
garbage collection) can be used on different heaps, depending on their 
particular reqt;'.irements . 

Xn the preferred emboaiment , the system further includes a bit array, 
having one bit for each possible object location in said portion of 
stor^ige. The bit is used to provide A quick indication of Whether or not 
there is an object currently stored at the corresponding object location, 
which is useful in operations euch as garbage collection 

The invention further provides a method of operating a computer 
system providing ojn object-based environment, said computer system 
including storage, a contiguous linear portion of which is logically 
divided into first and second heaps located at opposite ends of the storage 
portion, with any gap between the two heaps representing an unallocated 
region of storage, wherein refer^^nces are peirmitted from objects on the 
first heap to objects on the second heap ajid vice versa, said method 
comprising the steps of ; 

operating a. garbag-e collector across both neaps to remove objects 
that are no longer live,- 

escpanding the first heap into said unallocated region according to a 
first expajision policy; and 

for expanding nhe second heap into si;*id unallocated region according 
to a second expansion poiicy. 

The invention further provides a computer program product comprising 
instructions encoded on a computer readable medium for causing a computer 
to perform the method described above. A suitable computer readable medium 
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may be a DVD or computer disk, or the instructions may be encoded in a 
signal transmicced over a network: from a server. 

It will be appreciated chat the method and computer program product 
of tihe inxrention will bi^nefit farom the same preferxrcd £cQ.tures as the 
syacem or ttie invention. 

Br-ief Description of ctie Drawings 

A prefejTjred embodiment of the invention will now be Cescribed in 
detail by way of example only with reference to the following drawings: 

Figure 1 shows a schematic diagram of a computer system supporting a 
Java Virtual Machine (JVM) ; 

Figuare 2 is a. schematic diagr-am o£ the incearnal struccure of nhe OVPi; 

Figure 3 is a flowchart depicting the steps required to load a class 
and prepare it for use; 

Figure 4 is a riowcharc depicting at a high level the serial reuse of 

c* OVM; 

Figure 5 is a schematic diagram showing the heap and its associated 
components in more detail ; 

Figures and 6B rorm a flowchart illustrating garbage collection; 
Figure 7 is a flowchart: illustrating heap expansion policy at a high 

level ; 

Figure 8 is a diagram of a lookup table used to determine if a 
reference is in a. Ke^p; 

Figure 9 is a diagram of a modified lookup sriructure for the same 
purpose as Figure 8, but for use in a system with much largear memory,- sixici 

Figux-e3 lOA and lOB form a flowchart illustrating the operations 
taken to delete the transient heap during JVM reset. 

Detailed Description 

Figure i illustrates a computer system 10 including a 
(micro) processor 20 which is used to run software loaded into memory 60. 
TJne coftwaare can be losLdod into the memoiry by various means (not Shown) , 
for example from a removaJble storage device such as a floppy disk, CD ROM, 
or DVD, or over a network such as a local area network (LAN) , 
telephone /modem connection, or wireless link, typically via a hard disk 
drive (also not shown) . Computer system runs an operating ftyi?tem (OS) 20, 
on top of which is provided a Java virtual machine (JVM) 40. The JVM looks 
like an application to the (native) OS 30, but in fact functions itself as 
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a virtual operating system, supporting Java application 50. A Java 
application may include mtiltiplo thjrea.<is^ illustr-atcd by th-reads Ti and T2 
71, 72, 

5 System 10 cilso s\ippor*bss middleware subsystem 45, for example a 

trainsaction processing environment such as CICS, available from IBM 
Corporation (CICS is a. tr-adomsir-k of IBM Corporation) . The midaieware 
subsystem runs as an application or environment on operating system 30, and 
initiates tiie JVM 40. Th.e middleware also includes Java programming which 
10 acts to ca^aoe tr-ansactions as Java applications 50 to run on top of the JVM 

40. In accordance with the present invention, and as will be des:cribed in 
more detail below, the middleware can cause successive transactions to run 
on the same JVM. in a typical server environment, multiple JVMs may be 
running on computer system lo, in one oar more middleware environments. 

15 

It will be appreciated that computer »ys;t«»m lO Gsm be a snandard 
personal compTacer or workstation, network computer, minicomputer, 
mainframe, or any other suitable computing device, and will typically 
incliide many other components (not chown) such as display screen, keyboard, 
20 sound card, network adapter card, etc which are not directly relevant to an 

understanding of the present invention. Note that computer system lo may 
also be an embedded system, such as a set top box, handheld device, or any 
other hardware device including a processor 20 and control software 30, 40. 

25 Figure 2 shows the structur*? of JVM 4 0 in more detitil (omitting oomc 

components which are not directly pertinent to an understanding of the 
present invention) . The fundamental unit of a Java program is th« cla.ee, 
and thus in order to run any application the OTVM must first load the 
classes forming and required by that application. For this purpose the JVM 

30 includes a. hi^aijrarchy of class loaders 110, which conventionally includes 

three particular class loaders, named Application 120, Extension 125, and 
Primordial 130. An application can add <<dditional clacG loaders to the JVM 
(a class loader is itseir effectively a Java program) . In the preferred 
embodiment of the present invention, a fourth class loader is also 

3 5 supported. Middleware 12 4 , 

For each class included within or referenced by a program, the JVM 
effectively walks up the class loader hierarchy, going first to the 
Application class loader, then the Middleware loader, then the K^ctension 
40 class loader, and finally to the Primordial, class loader, to see if any 

class loader has previously loaded the class, if the response from all of 
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the class loaders is negative, then the JVM walks back down the hierarchy, 
with Che Primordial class loader first attempting to locate the cl^ss, by- 
searching in me locations specified in its class path definition. If this 
is iinsuccessf ul . the Extension class loader then makes a similar attempt. 
S if this fails the Middleware class loader tries. Finally, if this fails tne 

Application class loader tries to load the class from one of the locations 
specified in its class path (if c.hi& fails, or if cKere ie come other 
problem such as a security violation, the system returns an error) . It will 
be appreciated that a different class path can be defined for each class 

XO loader. 

Note that if it is desired to load a further middleware class loader 
(i.e. one provided by the user rather than included within the OVM itself) , 
then this can be achieved by d^clAring that the new class loader implements 
15 the middleware interface. This declaration by itself is sufficient for the 

JVM to treat it as a middleware class loader - no other method definitions= 
or cuch- li>ce are required . 

The JVM further includes a component C3j 204, which, al&o represent© a 

2 0 class loader imit, but at a lower level. In other words, this is the 

component that actually interacts with th^ operating cyGtem to perform the 
class loading on behair or the different (Java) class loaders 110 . 

Also present in the OVM is s. heap 140, which is used for storage of 
25 objects 14 5 (Figure 2 shows the heap 140 only at a high level; see Figure 5 

below for more details) . Each loaded class represents an object, and 
therefore can be found on the heap. In Java a class effectively defines a 
type of object, and this is then instantiated one or mor» tirr^^e in order to 
utilise the object. Each such instance is itseil an object which can be 
30 found in heap 140. Thus the objects 145 shown in the heap in Figure 2 may 

represent class objects or other object instances. (Note that strictly tile 
class loaders as objects are also stored on heap 140, although for the sake 
of cla.rity ttiey ;a.re shown separately in Figure 2) . Although heap 14 0 is 
Shared between all threads, typically for reasons of operational 

3 5 efficiency, certain portions of heap 140 cajn be assigned to individual 

throcLds, effectively a sn\a.ll region of local Storage, which Ccin be used 

in a similar fashion to a cache for that thread. 

The JVM also includes a class storage area 160, which is used for 
40 storing information relating to the class files stored as objects in the 

heap 140. This area includes the methoa code region 164 for storing byte 
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code for implementing class method calls, and a constant pool 162 for 
storing strings and other constants associated with a class. The class 
ocorage aarea. also inclvidec cx field d&ta region 170 for sharing SCaciC 
variables {static in this case implies belonging to the class rather than 
individual instances of the class, or, to put thi© smother way, shared 
becween all instances of a class) , and an area 168 for storing static 
initialisation methods and other specialised methods (separate from the 
nidin mcchod. code 164) . The class storage area further includes a method 
block area 172, which is used to store information relating to the code, 
KVLch invokers, and a pointer to the code, which Tna.y for eacamplc be in 

method code area 16 4, in JIT code area 18 5 (as described in more detail 
below) , or loaded as native code such as C, for example as a dynamic link 
library (DLL) . 

Classes stored as objects 145 in the heap 14 0 contain a reference to 
their associated data such as method byte code etc in class storage area 
160. They also contain. ^ reference to the class loader which loaded them 
into the heap, plus other fields such as a flag (not shown) to indicate 
whether or not they h^vo been initialiced. 

Figure 2 furch^ir shows Sl monitor pool 142. This containo a. set of 
locks (monitors) that are used to control access to an object by different 
threads. Thus when a thread requires exclusive access to an object, it 
first obtains ownership of its corresponding monitor. Each monitor can 
maintain a queue of threads waiting for access to any particular object. 
Hash cable 141 is used to map from an object in the heap to its associated 
monitor . 

Another component of the OVm is the interpreter 156, which is 
responsible for reading in Java byte code from loaded classes, and 
converting chi& into machine insr x-uccions for the relevant platform- From 
the perspective of a Java application, the interpreter effectively 
J5imu.lates the operation o£ a processor for the -virtual machine , 

Also included within rhe JVM are class loader cache 18 0 and g;^rbj;».g4Bk 
collection <GC) unit: 175. The former is effectively a table used to allow a 
Class loader to trace those classes which it initially loaded into the JVM. 
ThQ class loader cache therefore allows each claas loader to chec)c whether 
it has loaded a particular class - part of the operation of walking the 
class loader hierarchy described above. Note also that it is part of the 
overall security policy or the JVM that classes will typically have 
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different levels of permission within the system based on the identity of 
Che c=la*=c lo^^deir i>y which they were originally loaded, 

Garb;age collection. <GC) fa^cilicy 17S is used to delete objects from 
5 heap 140 when those objects are no longer required. Thus in the Java 

programming language, applications do not nood to cpecifically request or 
rrclcaae mcsmory, racher tnis is controlled by the JVM. Therefore, when Java 
application 50 creates an object 145, the JVM secures the recjuicit^ memory 
resource. Then, when Java application 50 finishes using object 145, the JVM 
10 can delete the object to free up this memory resource. This latter process 

is known as garbage coll<atction, a.nd is generally performed by briefly 
interrupting all threads 71, 72, and scanning the heap 140 for objects 
which are no longer referenced, and hence can be d^aleted. Tiic garbage 
rrollcction of the preferred embodiment is described xn more detail below. 

15 

Th^ JVM further includes a just-in-time <JIT) compiler 190. This 
forms machine code to run directly on the native platform by a compilation 
process from the class files;. Tlie machine code is created typically when 
the application program is started up or when some other usage criterion is 
2 0 met, and is then stored for future use. This improves run-time performance 

by avoiding the need for this code to be interpreted later by the 
interpreter 156 . 

Another component of the JVM is the stack area 195, which is used for 

2 5 storing the atcicks 155, 13 8 associated with the execution oC different 

threads on the JVM. Note that because the system libraries and indeed parts 
of the JVM itself are written in Java, and these frecpaently xzsc 
multi -threading, the JVM may be supporting multiple threads even if the 
user application 5 0 running on top of the jvm contaLins only a single thread 
30 itself. 

It will be appreciated of course that Figure 2 is simplified, ana 
essentially shows only those components pertinent to an understanding of 
the present invention. Thus for eacample the heap may contain thousands of 

3 5 Java objects in order to run Java application 50, and the JVM contains many 

other components {not shown) such as diagnostic facilities, etc. 

Figure 3 is a flowchart illustrating the operations conventionally 
performed to load a. class in order to ru.n a Java application. The first 
40 operation is loading (step 310) in which the various class loaders try to 

retrieve and load a particular class. The ne^ct operation is linJcing, which 
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comprises three separate steps. The first of these is verification (step 
320) , which essentially checJcs that the code represents valid Java 
programming, £oar exainple that each inat xniction has a valid, operacional 
code, and that each branch instruction goes to the beginning of another 
instruction (rather than rhe middle of an instruction) . This is followe<a by 
prcpaxacion (Step 330) Which amongst otiher things creates the static fields 
for a class. The linking process is completed by the step of resolution, in 
which a eymbolic ^reference to another class is typically replaced toy a 
direct reference (step 340} . 



At resolution the JVM may also try to load additional classes 
associated with the currenc class. For example, if the current class calls 
a method, in a. second class then che second class may toe loaded now. 
Likewise, if the current class inherits from a superclass, then the 
15 superclass may also be loaded now. This can then be pursued recursively; in 

other words, if the second class calls methods in further classes, or has 
one or more superclasses, these too may now be loaded. Note that it is -up 
to the crvM implementation how many classes are loaded at this stage, as 
opposed to waiting until such classes are actually needed before loading 

2 0 them. 

The £in=Ll i?t»p in Figure 3 is the initialisation of a loaded clasa 
(Step 350) , which represents calling the static initialisation method {or 
methods) of the class. According to the formal aVM specif ic-at ion, thie 
25 initialisation must toe performed once aJid only once before the first active 

use of a clriss, and includes things such as setting static (class) 
var-iablee to their initial values (eee the above-mentioned book by Lindholm 
ajnd Yellin for a definition of "first active use"). Note that 
initialisation o£ an object a1j;o sroquir^s initia.licat ion of its 

3 0 superclasses, and so this may involve recursion up a superclass tree in a 

similar manner to that described for resolution. The initialisation flag in 
a class object 145 is set as part of the initialisation process, thereby 
ensuring that the class initialisation is not subsequently re-run. 

3 5 The end result of the processing of Figure 3 is that a class has been 

loaded into a consistent and predictaJble state, and is now ^v^iil^ibl^ to 
interact with Other classes, in fact, typically at start up of a Java 
program and its concomitant OVM, some 100 0 objects are loaded prior to 
actual running of the Java progr-am itself, these being created from many 

4 0 different classes. This gives some idea of the initial delay and overhead 

involved in beginning Java application . 
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As mentioned above, the problems caused by this initial delay can be 
gr-ea-tly r-cducdd by serial areucc o£ a JVM, thereby avoiding che neea CO 
reload system classes and so on. Figure 4 provides a high-level flowchart 
5 of a preferred method for a.cHieving such serial reu.se . The method comrncnces 

wicn the start or the middleware subsystem 45, which in turn uses the Java 
Native Interface (JNI) to perform a Creare jVM operation (step ^xo) . M^xt 
an application or cransaction co run on the JVM is loaded toy the 
Application class loader 120, The middleware includes Java routines to 
10 provide v5^.riouB services Co the application, and those are also loaded at 

this poinu, by the Middleware class loader 124. 

The application can now be run (step 420) , and in due course will 
finally terminate. At this point, instead of terminating the JVM as well as 

15 the application, the midd] e^-'are subsystem makes a Reset JVM call to the JVM 

(step 430) . The middleware classes may optionally include a tidy- up method 
and/or a reinitialize metKod. Both of these are static me t hods - The JVM 
responds to the Reset J^TM by- calling the tidy-up method of the middleware 
classes (step 440} . The purpose of this is to allow the middleware to leave 

20 Che JVM in a tidy State, for example removing resources and closing files 

that are no longer required, and deleting references to the application 
objects. In particular, all those midcileware clarsses which have been used 
since Che previous JVM reset (or since the JVM was created if no resets 
h.ave occurred) have their tidy -up method called ^ aoauming of couxrse thcit 

25 they have a tidy- up method (there is no requirement for them to have such a 

tidy-up method) . 

The tidy-up method may be similar to the finalise method of a class, 
which is a standard Java facility to allow an object to perform some 

30 close-down operation. However, there is an important difference in that 

tidy-up is a static method. This means that contr^iry to the finalise method 
it applies to the class rather than any particular object instance, and so 
will be called even if there are no current object instances for that 
class. In addition the timing of the tidy-up method is diiierent rrom 

35 finalise, in that the former is called in response to a predetermined 

command to res^et the jrvM. In contrast, in acc!or<iance with the JVM 
specitication, the finalise method is only triggered by a garbage 
collection. More particularly, if an object with a finalizer method is 
found to be unreachable during a garbage collection (ie it is no longer 

40 effectively active) then it is queued to the finalizer thread, which then 

runG the finalizer method after the garbage collection is completed. Note 
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that the finalizer method of an object may never be call&d, if 
applicacion finishes and the JVM shuts dovm without che system needing to 
perfoarm 9^ garbag-e collection. 

5 Once the tidy -up has been corapletedl, refresh h«ap operation is 

performed (step 445) . AS will be Qescribecl in more detail below, this 
deletes those portions of the heap that relate to the application or 
trancaction tKac hao just kreen cotnpleteci, generally analogous to a garbage 
collection cycle. Note that many of the objects deleted here might not have 
10 been removaJble prioar to the tidy -up method, since they could still have 

been referenced by the middleware classes. 

At this point, the middleware subsystem maJces a determination of 
whether or not there is another application to run on the avM (step 450) . 
15 If not, the middleware subsystem uses the JNI to make a Destroy JVM call 

(step 460) which terminates the JVM, thereby ending the method of Figure 4. 
If on the other hand there ie ?Jinoth©r a.pplic5ition to jrun, then this new 
application is started by the middleware. The system responds to this new 
application by calling in due course the reinitialisation method in each of 

2 0 the middleware classes to be reused (step ^55) . The purpose of this is tO 

allow the middleware classes to perform certain operations which they might 
do at initialisation, thereby sidectcpping tHe restriction tbac the JVM 
specification prevents the initialisation method itself being called more 
than once. As a simple example, the reinitialis^ition may be used to reset a 
25 clock or a counter, as shown in Figure 4, the system is now in a position 

to loop round and run another application (step 420) . 

It is generally expected that the reinitialisation method will be 
similar in function to tiJne initialisation method, but there may well be 
30 some differences. For example, it may be desired to reset static variables 

which were initialised implicitly. Another possibility is to allow some 
state or resources to persist between applications; for example, if a class 
always outputs to one particular log file which is set up by the 
initialication method, it may be more efficient to keep this Open in 

3 5 between successive JVMe, trsmsparent to the application. 

It should_be notea that whilst Figure 4 indicates the distinct 
logical steps performed by the method of the invention, in practice these 
cteps arc not all independent. For example, calling the tidy-Up methods 
40 (step 440) is part of the overall reset JVM operation (step 430) . Likewise, 

c;a.lling th« reinitialiaation methods (step 455) is effectively part of the 
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start-up processing of running tiie new application {step 420) . Thus 
reinitialisation is performed prior to first active use of a class, and 
this may occur at any stage o£ a parogram. Therefore class reini tiallsacion 
(like conventional initialisation) is not necessarily completed at starc-up 
of Che program, but rather can be regarded as potentially an ongoing 
proceee througho-at the rxmning of a program. 

It will ^xlso be appreciated that there is some flexibility witn 
regard no the ordering of the steps shown in Figure 4 . In particular, the 
decision of whether or not there is to anotHer application {step 450) 
could be performed earlier, sucn as prior to the refresh heap step, the 
tidyup step, and/or the reset JVM step. In the latter case, which 
coarrefiponds to immediately after Che first application has concluded (i-e, 
straight after step 420), the alternative outcomes would be co destroy the 
15 JVM (step 460) if there were no further applications, or else to reset f,he 

JVM, tidy up, refresh the heap, and reinitialise {steps 430, 440, 445, and 
4S5) if there were further applications, if inctfi^ad the decision step 450 
is intermediate there above two extreme positions, the logic flow csji be 
determined accordingly. Further details about the implementation o£ tin« 

2 0 tidynp and reinitialise methods arc provided in above -mentioned US patent 

application 09/584641, 

rt should be notea tnat in the preferred etnbodiTnent , the ability to 
reset the JVM, and to have tidyup and reinitialise methods, is only 
25 av<ailablc for middleware classes {i.e. those loaded by the middleware class 

loader) . This is to allow t'ae middleware classes to be re-used by 
successcive applications or transactions, for wiiich they can perrorm various 
services. The basis for this approach is that typically the middleware is a 
relatively sophisticated and trusted application, and co csm be allowed to 

3 0 take responsibility tor proper implementation of the tidy- up and 

reinitialise methods. On the other hand, the transactions that run within 
the middleware are not treated as reliable . 

Note 5ilso that the system classes themselves do not have tidyup or 
35 reinitialisation methods, despite persisting across a JVM reset. Rather, if 

the middleware makes any change to a system class, then tti* middleware 
itself is c3cpected to take the necessary action (ir any) for a reset with 
respect to the system class as part of the middleware's own tidyup 

operation . 

40 
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An important part of Che reset JVM/tidyup operation (steps 430 ajid 
440) in the preferred einbodiment is to make sure that the JVM is in a state 
which ie amexiaLk>le to being tidied up. If tlnic ic the csiee. th^ JVM iff 
regarded as being clean, if not, it is regarded as being dirty or 

5 corxtamiixa-ted . 

Considering this in more detail, if the application has performed 
certain opezratione , then it will not be possible for the middleware cla-sees 
to be certain that their tidy-up and reinitialise methods will fully reset 

3^0 th© jsyftCftm CO a fresh state. With euch A contaminated JVM, the system still 

calls the tidy-up methods of the class objects as per normal (step 440) , 
but the return code back to the middleware associated with the reset JVM 
operation (seep 43 0) erf eccively indicates failure. The expectation here is 
that the JVM would actually be terminated by the middleware subsystem at 

15 this p^-int, as it is no longer in a predictable condition. 

One important situattion which would prevent the JVM from being able 
to properly reset is where the application has performed certain operations 
directly such as making security or environment changes, running native 

20 code, or performing Abstract Windowing Toolkit <AWT) operations. Those 

affect the state of the JVM or the underlying computer system and cannot be 
reliably tidied u.p by the middleware, for the srimple reason that th^ 
middleware does not necessarily know about them. Such changes could then 
persist through a reset JVM call, and contaminate the JVM for any future 
25 applications, in concrasr, if an application performs sucn operations 

through a middleware call, then this does not cause any problems, because 
ttic middleware now does know about the sitviation cmd co ocun perform 
whatever tidyup measures are required. 

3 0 The JVM thus monitors for operations that may prevent proper resen, 

including whether they have been performed by an application or middleware. 
This is determined by the JVM keeping track of its context, which is set to 
application context for an application class, and to middleware context for 
a middleware class, wtiilst a primordial or excension class has no impact on 

35 the existing context of application or middleware. In particular, context 

c^xx be determined based on the type of class which contains the method that 
is currently toeing perrormed, whilst the type o£— class is determined from 
its original class loader. 

40 As previously mentioned, the list of problematic operations given 

above only causes difficulty wVien performed in an applic^ition context. 
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since in . a middleware context ic is possible for them to be reset by the 
appropriate tidy-up routines of the relevant middleware classes. 

Referring now to Figure 5. in the preferred embodiment the heap 140 
is logically split inno three components (objects in one component c^n 
arefer-enc© objects in another component). In particular, ac the bottom 
(logically) of heap 140 is middleware section 510, and at the top of the 
heap is transient szeation 52 0. The data in tiiecc two heap© grows cowards 
each other, tihus transient heap grows in the direction of arrow 521, and 
middleware heap in the direction of arrow sil. Tbe mi<ddlewa.r-e h^ap is 
defined by boxmdary 5x2, and the transient: neap by boundary 522, with 
unassigned space 515 between them. It should be appreciated that boundaries 
S12 and 522 r"ep3r©eent the mo^cimvim size curr-ently assignee^ CO Che two heaps, 
rather than their current fill levels - these are instead shown by dashed 
lines 513 and 523. In ocher words, as the middleware heap fills up, the 
fill level 513 will approacn towards middleware heap boundary 512; likewise 
as the transient heap fills up, the fill level 523 win appiro^^ch towards 
caranoient heap bovindaary 522. Finally, and separace from the transient heap 
and middleware heap, is system heap 550. Note that the combined transient 
and middlewaire h^ape , togechor with intervening uiaassigncd space, are 
allocated from a single physically contiguous block of memory 560. In 
contrast, the system heap 55 0 may be formiad from multipls non-concxg-uo-us 
regions of memory. ^ 

Xn one paref erred embodiment, memory 56 0 comprises 64 MBytes, and the 
i-'T-itial size of trhe middleware and transient heaps is O.S Mbyce each. Thus *, 
it can be seen tliAC inihia.lly ir3n« unassigned region 515 dominates, although 
as will t>e discussed in detail below, the transient and middleware heaps 
are allowed to expand into this space. However, these values ar-e eMdmplsiary 
3 0 oiily, and suitable values will vary widely according co machine 

architecture and size, and also the type of application. 

Heap control block 53 0 is used for storing various informa.tion about 
the heap, such as the location of the heap within memory, and the limits of 

35 the transient and middleware sections as defined by limits 512 and 522, 

Free chain block 532 is used for listing available storage locations: withirL 
the middleware and caransient: sections (chere is actually One free Ctialn 
block for each section) . Thus although the middleware and transient heaps 
start to fill $=e<iutf*nt:i silly, the likely aresvilt of a gairbcLg-c collection cycle 

^0 is that space may become available within a previously occupied region. 

Typically therefore there is no single fill line s^jch S13, S23 between 
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vacann and occupied space, rather a fragmenced pattern. The free chain 
block is a linked list which specifies the location and sise of empty 
regions wichin that =cccion of che heap, ic is quick to determine whether 
and where a requested amount of storage is available in the he^xp by simply 
S scanning through the linked list. Note that in the preierrea embodiment, 

empty regions in the heap which are below a predetermined size (typically a 
few hundred bytes) are excluded from the free chain lisc. This prevents che 
list from becoming coo long through containing a large number of very small 
vacant regions, although it does mean that these regions effectively become 
10 inaccessible for storaer© (although chey can be retrieved later, as 

describea in more detail below) 

The transient heap 52 0 is used for storing objects having no 
expected currency beyond che end of the applieation or transaction, 
including application object instances, and primordial object instances and 
arrays created by application methods (arrays can be regarded as a 
specialised form of object) . since che lifetime Of such objects is 
commensurate with the application itself, it should be possible to delete 
all the objects in the transient heap at the end of che application. The 
application class objects are also on the transient heap. In contrast, the 
middleware heap 510 is used for storing objects which have a life 
expectancy longer than a single transaction, including middleware object 
instances, and primordial object instances and arrays created by middleware 
methods. In addition, string objects and arrays for strings interned in the 
rntemed string Table are also stored in the middleware heap (the Interned 
String Table is a tool whereby if multiple identical strings are to be 
stored on the heap, it is possible CO Store only one copy of the string 
itself , which can then be referenced elsewhere) . Lastly, the cyatem heap 
550 is used for storing primordial class objects and reusable class 
objects, where Che term reusable class object is used to denote a class 

Wiaich can be used SLgain ^ift^ar Jtvm reset. 
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The type of class is dependent on che claca loader wKicH originally 
loaded it, in otner words a midaieware class and an application class are 
loaded by tHe middleware class loader 124 and nhe application class lo^^d^zr 
12 0 respeotiv^ly. For tKe p^^rpoocs of the preseni: aiscusslon, primordial 
Classes can be considered as classes loaded by the Primordial or Extensions 
class loader (130 and 125 respectivisly in Figvi:re 2>. in the pirc£cr:red 
embodiment, classes loaded by the middleware class loader are automatically 
40 regarded as reusable. 
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IZ is clear from above chat instances of primordial classes, such as 
Che basic string class java/lang/Scring, can be located either in the 
middleware hsap or the transient heap, depending on the method whicn 
created chem. In a preferred embodiment of Che present invention, che 
decermination of where to place such primordial class inotances is based on 
the current concexc described above (also referred to as method- type ) . Thus 
if a method belonging to an application class is invoked, the context or 
method-type becomes Application, whilst if a method belonging tO a 
middleware class is invoked, the method-type becomes Middleware, Finally, 
if a method belonging to a primordial class is invoked, the method- type is 
unchanged from its previous value. The context or method- type is stored in 
Che Java frame for che method (which is stored on stack 195 - see Figure 
2) ; at the completion of che mechod, che method- type reverts to its value 
at the time the method was invoked, which was stored in the previous fr-ame. 

It should be noted that for the above purpose a method belongs to the 
class that actually defines it. For example, if class A sui,clacocs class B, 
but docs not overridr; method c, then method C belongs to class B, Therefore 
the method- type is Chat of class B, even if method C is being rxm for an 
instance of clciss A. in addition, the reason for cracKing method-type on a 
per-thread basis is that it is possible for various threads within an 
application co be executing different methods having different concexc. 

The transient region of the heap, containing objects created by the 
application or transaction, is subject to normal garbage collection, but 
the intention is that it will be sufficiently large that this is unlikely 
to occur within the lifccime of cl typical application. AC Che end Of each 
application, che transient region of the heap is reset, (The repetition of 
this pattern will thereby avoid having to perform garbage collection during 
30 most cyplcal applicacions) , In concrast the middleware region generally 

contains objects created by the trusted middleware, it ia again subject to 
conventional garbage collection, although in a transaction environment it 
is expected chat the majority of objects will be created in the transient 
heap, CO tKat garbage collection is not expected to occur frequently. 
35 Moreover the system typically tries co perform garbage collection of the 

middleware heap at the same time as reszec of the transient heap, in other 
words between rather chan during transactions (this is discussed in more 
detail below) . The middleware heap is not cleared between applications, but 
rather remains; to give the middleware access co ics persiscenc scate (it is 
40 assumed that che middleware can take responsibility for resetting itself to 

the correct state to run th© next application) . 
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The preferred embodiment is actually somewhat more complicated than 
described above, in chat it supports two types of a.ppli elation cIsibb loader y 
one of which is for standard application classes, the other for reusable 
5 application classes. The motivation here is that when the next transaction 

ic to rvm, it will in fact rccruiro many of the same application classes as 
the previous transaction. Therefore it is desirable to retain some 
application system classes rather th^n h^^ving to reload them, althoug-h 
certain additional processing is required to make them look newly loaded to 

10 the next transaction. Conversely it would be possible to have a second 

middleware class loader which is for non-reusat)le miadleware classes. In 
the former situation the reusable application classes are treated 
ecf^Mnti Silly in the came manner as the reucablc middleware clcLsrses, (eg 
loaded into the system heap) ; in the latter situation the non- reusable 

15 middle. ^<-^re classes would be treated similarly to the non- rei?. sable 

application classes t>ut loaded into the middleware heap (since they may 
exist after the conclusion of a transaction, even if they do not endure for 
the neict transaction) . However, for present purposes in order to explain 
the invention more clearly, it will be assumed that all the middleware 

2 0 classes are re\i*??ifcl», and that none of the application clACCCS arc 

reusable. 

The introduction of multiple heaps for different types of objects 
allows the handling of the heap to be fine-tuned to the reouirements of 

25 those typos o£ object. Por example, it may be desirable for the transient 

heap to allocate a larger thread local heap cache. In addition, utilising a 
single block of memory for the trains i<3nt and middleware h«aps improves 
space usage, in that a given region of memory can be flexibly assigned to 
either the transient or middleware heap, depending on particular 

30 application requirements. On the other hana it aoes lead to some 

complications in terms of heap management, especially as regards control of 
heap size. Thus in simple terms, as more and more objects are created, 
there is a choice to either enlarge the size of the heap, or to perform a 
garbage collection to maintain the heap within curr«cnt size limits. The 

3 5 former option is generally quick, but will eventually lead to the 

exhaustion of heap space; in contrast, a garbage collection is relatively 
slow, aince it interr-uptrs processing/ but does constrain the heap size to 
Within predetermined limits. Overall, the preferred embodiment tries to 
avoid garbage collections; duaring tranaactions as much ac possible, therehy 
^0 optimising performance for the transaction, amd to rely instead on the heap 
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refresh described below, which, is performed at the end of the transaction 
as part of che JVM reset. 

More specifically, the policy for expansion and garbage collection in 
5 teannc of system hea.p 550 is stirsiight forward, in chjic oljjeccs in this he«Lp 

are never garbage collected; rather Chis heap simply expands to accommodate 
all relevant class objects. However, the policy for tramsient and 
miaaieware lieaps is more complex, because chese cwo heaps are 
interdependent, in that they share Che same memory space. In order to 
10 better- vxndcrctaxid this policy/ it will b© Helpfu.1 to firstly review in more 

detail the garbage collection strategy of the preferred embodiment, as 
shown in Figures 6A and 6B. Xn particular, the method involves firstly a 
marJc pnase, wnlcn mar)cs all objects in the heap that are currently in use 
{Jcnown as live or active objects) , and secondly a sweep phase, which 
lb represents the actual deletion of objects from Che heap. Note that general 

background on garbage collection algorithms can be found in "Garbage 

Collection: Algorithms for Automatic Dynamic Memory Management" by R Jonee 
and R Lins, Wiley, 1996 (ISBN 0 471 94148 4) . whilst one implementation for 
garbage collection in a system having multiple heaps is described in: ^^A 
2 0 customisable memory management rrameworK for C++" by o Attardi, t Flagella, 

and P IgliOv in Software Practice and Experience, vol 28/11, 1998, 

As shown in Figure 6A, the method scares with a review of the 
r<5gistere sind eCACk, both, th*? JAva rtiagIc, as *5hLOwn in Figure 2, and also 

25 the C Stack, (assuming that the JVM 40 is running as a C application on OS 

30, see Figure 1) (step 610). Each thirty-two bit data word (for a 32-bit 
system) contained ttierein could represent anything, for example a real 
number, or part of a string, but it is assumed at least initially that it 
may denote a 32 biC Jrcfearence to an object location in the heap. To firm \xp 

30 on this assumption, three tests are made. Firstly, it is tested whether or 

not the number references a location within the heap (step 612) ; if not 
then the number cannot represent an object reference. Secondly, in the 
preferred embodiment, all objects commence on an 8-byte boundary. Thus if 
the location corresponding co the data. word, from the stack./rcg-i=ter does 

35 not fall on an object boundary (tested at step 615) , then the original 

assumption that th^ d-ata/nunvber represents a reference to the he^p m\isc 
again be rejected. Thirdly, in the preferred embodiment, a table 538 is 
maintained (see Figure 5) which has a bit for each object location in the 
neap; tnis bit is set to unity if there is an object stored at ctiat 

40 location, and zero if no object is stored at that location (the relevant 

bit i=3 upddtcd cippropriatcly whenever an object is created, deleted, or 
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moved). If the data word from the stack/register corresponds to an object 
location for which the bit is zero, in other words, no object at that 
location, then once more ctie original assumption that the data/number 
represents a reference to the heap must be :ri?jected (step 620) . if the data 
word pAssec All three of the tests of steps 612, 615 and 620, then there 
are three remaining possibilities: (a) the word references: an object on the 
heap; (b) the word ic an integer that happens to liave tile same value as the 
object reference; or (c) the word is a previous value from uninitialized 
storage. As a conservative measure, it is assumed that option (a) is 
co3rr-«ot, and so the= object is marKed as live (step 625) . A special array of 
bits is provided (block 534. see Figure 5). one bit peir object, in order to 
store these mark bits. If there remain other values on the stacks/registers 
to test (step 630) , the method then loops back to examine these in tbe eanie 
manner as just described; if not the first stage of the mark: process is 
15 complete . 

In the second stage of the mark process, shown in Figure 6B, the 
objects marked as live are co,^ied onto a list of active objectc (step 63 5) 
(in the prefeirared embodiment objects axe actually copied to the active list 

2 0 when originally marked, ie at the same time as step 625 in Figure 6A) . An 

object from this list is then i?^lected (step 640), and examined to see if 
it contains any references (step 645) . Note that this is a reasonably 
straightforward procedure, because the structure of the object is known 
from its corresponding classss file, wnich defines the relevant variables to 

25 be used by the object. Any objects referenced by the selected object are 

themselves marked (step 650) and added to the active list (step 655) . Next, 
the selected object is removed from the active list (step 660) , and then a 
test is performed (step 665) to determine i£ the active list is empty; if 
not, processing loops back to Step 64 0 to select another object from the 

30 active list. Finally, when step 665 produces a pos:itive outcome, all 

objects that are active, because they are referenced directly or indirectly 
from the stacks or registers, have been appropriately marked. 

The mark stage is then followed by a sweep stage (step 670) and a 
3^ compact stage (step 675) . The former garbage collecnc (i© deletes) all 

those objects which have not been marked, on the basis that they are no 
longer reachable from any live or active object. In particular, each object 
which is not marked as active has its corresponding bit set to zero in 
table 538 (see Figure 5). Runs of zeros in the bit allocation table 538 are 
40 now identified; these correspond to some combination of the object 

immediately preceding the run, wiiich may extend into the run (since only 
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nhe head of an object is marked in the bit allocation cable) , and free 
space (released or never filled) . The amount of free cp:;ic^ in the r\in of 
zeros can be determined by eacamining tine Size or the object immediately 
preceding the run. If the amount of free space exceeds the predetemvined 
5 minimum atnounc mentioneci earlier, then the r\m is addca to the Tree chain 

list 532 (see Figure 5) . 



Over time, sucn sweeping will tend to produce many discontinuous 
vacant regions within the heap, corresponding to the pattern of deleted 
ot>jecte. TKic does not represent a particularly eCricient configuration, 
and in addition there will be effective loss of those pieces of memory too 
small to be on the free list . Hence a compact stage (step 675) can be 
performed, whicn acts to squeeze together those objects which remain in the 
heap after the swee^ in order to amass tihem into j?. eing-le continuous blo^k 
of storage (one for the transient heap, one for the middleware heap) . 
Essentially, this means relocating objects from their initial positions: in 
the In^Ap, to a now position co that, as much a.s possible, they are all 
adjacent to one ^»".ioth3r. As part of this compaction, the very small r.:*gio:is' 
of memory too small to be on tJrxe free chain 532 (see Figure 5) should be 
aggregatea into larger blocks that can be recorded in the free chain. 



An important rcguircmenc of the Object relocation of the compaction 
step is o£ course that references to a moved object are altered to point to 
its new locsition. This is a relatively otraigKtf orward operation for Object 
references on the heap itself, since as previously mentioned, they can be 
identified from the known structure of each object, and updated to the 
appropriate new value. However, there is a problem with objects which are 
directly referenced from a register or stack. As discussed above, each 
number in the rcgistcr/atack is treated for garbage collection purposes as 
if it were an object reference, but there is no certainty that this is 
actually the cas?,^ ; rsither th.e number may represent an. integer, a real 
number, or any other piece of data. It is therefore not possible to update 
any object references on the stack or register, because they may not in 
fact be an object reference, but rather some other piece of program data, 
which cannot of course be changed arbitrarily. The consequence of this is 
chc^t it is impossible to move an object which appears to be directly 
referenced from the heap or stack; instead these objects must remain in 
their existing position. Such objects? j^re informally known as "dozed" 
objects since they cannot lae moveG from their current position. 



Received 06-11-00 15:32 



Frofn-0ig62 818927 



To-THE PATENT OFFICE Page 29 



GB920000100GB1 

Two Other classes of objects which cannot be moved from the heap are 
class objects, and thread objects (thread objects are control blocks used 
CO store infc-rtnaCion aho^it ci thread) . The reason for this ic that such 
Q^jg^tB are referenced from so many other places in the system that it is 
5 not feasible to ch^ge all th*«j5^ other references. These objects are 

therefore Icnown as -pinned", since like dozed objects they cannot be moved 
from their current position. 

A consequence of pinned and dozed objects is that a compact process 
10 may not be able to accumxilate all objects in a heap into ^ i=ingle 

contiguous region of storage, in that pinned and dozed objects must remain 
in their original positions. The consecfuences of this are discussed in more 
detail below. 

15 MCte that in the preferred embodiment, a compact stagr-. (step 675) is 

not necessarily employed on every garbage collection cycle, unless this is 
e>cplicitly requested as a \aser initial set-up option. Rather a compact 
ope.ration is only performed when certain predetermined criteria are met. 
For example, as previously indicated a garbage collection can be triggered 
20 by a request for storage in the heap thac cannot be satisfied, rf the 

request still cannot be satisfied after the sweep step 670, because there 
no single block of memory available of sufficient ciae, then a compiict 
tage is automatically performed, to try and accumulate an adequately-sized 



25 



13 

St 



storage rega-on. 



In the preferred embodiment, the further criteria used for deciding 
whetner to compact are different for the middleware heap o.nd the transient 
heap. Thus for the transient heap a compaction is performed whenever the 
amount of free space remaining in the transient heap after the g;&arbage 

3 0 collection is less than 5% of the heap capacity. The idea here is that when 

space app^^».*r£; to be arunning out, the compacting should retrieve some 
additional space from those empty regions too small for the free chain 
list- On the other hand, for the middleware heap more complex compaction 
algorithms are used, based for cjcample on when heap fragmentation e^cceeds 

3 5 certain limits (eg in terms of number of fragments) , or where the largest 

t>lock in the free chain list is bolow a certain size. The rationale here is 
that the middleware heap is likely to be or relatively long duration, and 
so it is worthwhile to try to optimise its overall storage arrangement, 

40 Note that although the triggers for garbage collection and compaction 

can be different for the middleware and trancient heap, wh^n <?ither 
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operation is perfomed, in the preferred embodiment it is performed on the 
whole of active storage 560 - ie on both the middleware *nd t«„sie„t 
sections simultaneo,^«=iy . This ie because incerheap rererences are 
permitted, and so any marking or compaction operation necessarily in^.olves 
both heaps. Consequently, once st^rcinj ^ garbage collection or compaction, 
it io most cffccicnt to do both neaps at the same time. 

on« complication to Che garbage- collection described above is that as 
previously mentioned, Java permits objects to have finalizer methods, which 
must be prior to deletion of cHe object in a garbage collection. In 

order to manage this requirement, certain additiox^i processixxg i= required 
(not shown in Figure G) . Thus when an object is created on the heap that 
has a finalizer method, a reference to that object is added to a «et of 
finalizer references. At the end of the mark phase of garbage collection, 
this set of fi.alizer references is scanned, to detect any objects in the 
sec which are not marked - the resultant group represente the objects which 
are about to bs deleted, and so neea to have their finalizer methods run. 
TO accomplish tiiis, objects in this group now need to be marked as xi^re. 
and their references iter^^tively traced also marked as live, in similar 

fashion as for the main mark phase. The purpose of this is firstly to 
retain the objects in order to run their fiiaaliser methods, and secondly to 
retain any other objects which are directly or indirectly referenced by 
thetn, so that the finalizer methods run correctly. The finalizer references 
for objects in this group are removed rrom the Set of finalizer references 
described above, so that their finalizer method will not be activated by 
any future garbage collection cycle, and passed to a reference hcndler. The 
subsequent processing is asynchronous, and does not occur until main system 
processing is resumed after the garb^ige collection hcis concluded (ie after 
the end of the processing o£ Figure 6B) . Once the reference handler has 
restarted, it passes any object finalizer references it received during che 
garbage collection to a fincxlizer cjueue. A separate finalizer thread then 
runs each entry in the queue in turn, deleting the object reference from 
the queue after the corre5=ponding finaliser method has been run. 

^^^^ objects referenced by the reference handler or on the 
finj^lizer queue arc regarded as "live- during a garbage collection process, 
in other words- they are marked along with any other objects which they 
reference, directly or indirectly. This ensures that objects do not get 
inadvertently deleted from the finalizer queue, if their wait on this queue 
exceeds the time to the next garbage collection. (Thus objects in the 
^reference handler and finaliaer queue form additional roots for live 
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Objects, in addition co those on the stacks and registers as iHustrated in 
Figure 6; in face in the prefeirred *n,toodimene. there arc other categories 
of roots, for example syscem class files, but the details are not 
pertinent to an understanding of the present invention) . 

One potential problem with the handling of finalizer methods 
described above i« th*e by ™ming them on dedicated thread (cue 
finalizer thread) . the context of che thread will be different from the 
main application thread, where context here indicates general system 
properties associated wich che thread, such as security permissions. This 
can be a particular concern in relation to transaction threads, which «e 
previously mentioned are regarded as relatively untrustworthy. Therefore, 
Che preferred embodiment modifies the handling of objects in the transient 
heap having finalizer methods, if the.^ located in a garbage collecclon 

cycle and are not marked, then as described above they are marked, along 
with the objects which they reference, directly or irxdir-otly . However, ao 
further procec=iiag is done on these objects. In particular, they are not 
removed from the sec of finalizer references, and are not passed to tho 
reference h^ndl^r. The effect of thio is chat these objecc chea simply 
concinue to appear to the garbage collection process as normal live 
objects, and are maintained through each garbage collection cycle. These 
object= are eventually deleted in the refresh heap step 445 of the JVM 
reset {see Figure 4). which will be described in more detail below. 

Returning now to the question of allocating heap space from che 
overall memory region 560, which contains both the middleware and transient 
secclons. the procedure for this is illustrated at a high level in Figure v 
(ac chis level the same general policy is used for both ch« middleware and 
transient heaps, although as Will be seen below, there are some significant 
differences in the details of their respective policies) . The process 
starts with an allocation request (^tep 705). typically CO score an Object 
on the heap. This causes the free chain block 532 (see Figure 5) for the 
relevant heap aeetion to be ejcamined; if there is available =pacc (seep 
715). then the method proceeds directly to allocating the desired space 
(step 795) . and exits successfully. 

On the other hand, if the tesc of step 715 is negative, then it means 
that the heap i^ too full to suatair. the aew allocation. This is equivalent 
conceptually to the fill level 513 in Figure 5 approaching the assigned 
boundary 512 for the middleware heap, or fill level 523 approaching 
assigned boundary 522 for the transient heap, in this situation, the system 
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first determines whether it is possible to simply expand the amount of 
space assigned to the heap (step 725) . In simple terms, for the middleware 
heap this corresponds to moving assigned boundary sia upwarda inco the 
unassigned region 515. thereby taking some of the unassigned storage and 
allocating it to the middleware heap 510; conversely for the t^an«ient 
Heap, boundary 522 is moved dowiiwards . Of course, ic is not possible for 
the middleware heap to encroach into the transient heap or vice versa, so 
that once the unassigned space 515 ha= been e^chauctcd, then it is no longer 
possible to expand the neaps further. In a situation where heap space is 
available, then a policy is defined to determine the amount of a^t^a apace 
to add to the heap. The genrral policy in the preferred embodiment is to 
increase the heap so that there is 30% free space (taking into account the 
new allocation ro<iueet). Howeve>r. a p^odotormin«d minimum expansion size 
is defined (0.5 MByte in the preferred embodiment), so chat the expansion 
is actually 3 0* or 0.5 MByte, whichever xn greater (subject of course to 
the amount of space available). biJcewise, the user may also set a maximum 
expansion size, which is then used to cap the figure just obtained 
(providinsr it does not prevent satisfying r.he current allocation request) . 
Finally, in the preferred embodiment, heap memory is always 
assigned/deassigned in units o£ a predetermined sisc, which for a 32 -bit 
system is 64 Kbytes for reasons that will be described later. Therefore 
whatever expansion value is determined based on the 30% expansion, thi= is 
adjusted to the appropriate whole number of 64 Kbyte units. Note that in 
the preferred embodiment, there are further controls on how the different 
he^ipa a>re allowed to e>tpand; these ar= discussed below in more detail. 

After the available e^aneion space has been determined, it is tested 
whether chere will now be sufficient space to satisfy the allocation 
request (step 735). If so, the relevant heap is duly e^anded (step 7B5) . 
i£ not, the method proceeds to step 745, and a garbage collection is 
performed. It is now checked whether or not this has created sufficient 
space (step 755) ,- if so. the method proceeds to allocate the requested 
space (step 795) . Note chat one minor complexity not shown in Figure 7 is 
chat the garbage collection (step 7as) may perform both a compact 
operation, and then also try a heap expansion (equivalent to step 785), i.t 
these are necessary to obtain the requested space. If on the other hand 
there ia atill insufficient cpace for Che- allocation requesc. then as a 
final measure, it is possible to shrink the other heap (step 765). Thus 
referring bacJc to Figure S, it can be «een that middleware heap could in 
principle lose the assigned but empty space between boundary 512 and fill 
level 513, by lowering boundary to fill level Sl3 . The reclaimed space 
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could then be transferred to the transient heap 52 0 (assuming chat it 
already now extended through the region 515 shown in Figure 5 as 
xinassigned) . Conversely, space could b*at n^Lde 3.va.ilable for transfer from 
the transient heap to the middleware heap by raising boundary 522 towards 
5 fill level 523- 

Following the shrinkage of the other heap (step 765) a test is now 
tx\ade to sct= if thio hae cireated su.£ficieat ©pace for the alloca.tiot\ sr^^gviect 
(step 775) ; if not the system must return an error to the allocation 
xo requeet (stop -780) indicating that no space is available. Assuming however 

that space is available, then the neap for which the allocation request is 
made can expand (step 78 5} into the space vacated by the shrinkage of the 
other h.eap , therelpy allowing- the allocacion r-ecpacst to bo caticfied (step 
795) . 

IS 

It will be appreciated that there are many possible variations on the 
processing shovm in Figure 7. For example Figure 7 shows heap expansion 
(step 785) only when this wial positively provide the Trccjuiired space (ie 
following a positive result from the tests of steps 735, 765, 775), but it 

20 will be appreciated thac such heap cxpanoion might be per-formed 

irrespective of whether or not this would create sufficient space for the 
SLllocation irecfuest £oir some or- ^».ll of these tests. In facc^ in the 
preferred embodiment, after garbage collection Has been performed (Step 
745) r the relevant heap will automatically try to expand to give 30% free 

2 5 space as previously described, even when tlic allocation recfuest has already 

been satisfied (this is subject to certain limitations described in more 
detail below) . 

In addition, £^r5i 5tttempt coTild be made to shrink the other heap (step 
30 765) before performing garbage collection (step 745) , or it may occur 

automatically as part of the garbage collection process. Thus in the 
preferred embodiment, the assigned boundary for the transient heap (line 
522 in Figure 5) is shrunk as much as possible each time the heap has been 
compacted, providing that this does not reduce the transient heap below its 
35 initial size. In contrast, although the middleware heap is also shrunk 

after compaction in the preferred embodiment, in general some leeway (such 
as 30* free space) is left between the heap boundary axid the fill level. 
The middleware heap is also never reduced below its original size. This 
policy balances the fact that the transient heap is allowed to grow more 
40 easily than the middleware heap (as discussed below) . More generally, such 

cKrinkage after compaction returns storage CO the xmassigned pool, and SO 
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increases flexibility for managing storage requests from the two heaps. 
Note that because in the preferred etnbodimenc shrinkage is p«r-fonned (if 
possible) after compaction, which in tum Will be performed if the garbage 
collection does not otherwise satisfy the allocation request, then to son,e 
extent steps Ias and 7e5 in Fig^are 7 arc effectively amalgamated together. 

Although the processing shown in Figure 7 applies ac a high level, 
there are important dirrerences in detail as regards the management of the 
transient and middleware heaps. The policies adopted reference a location 
56S which represents the midpoint between the middleware heap boundary S12 
and the transient heap boundary 522 (see Figure 5). as determined at JVM 
start-up or JVM reset. Thus for the middleware heap, the procedure is 
e^»nd Che heap rather tnan garbage collect, using the expansion criteria 
described above, until the heap would expand past ch- midpoint location 

situation does arise, then the system uses a smaller 
expansion increment, namely the minimum expansion value (ie 0.5 Mbyte in 
the preferred embodiment) . Finally, if even this reduced ej^ansion would 
still ta3ce the mi.ddleware heap past the midpoint, then a garbage collection 
is performed (ie step 745). rather than allowing the middleware heap co 
2 0 e^spand further. As previously indicated, a compaction will be performed 

here if necessary to satisfy the allocation request. After the garbage 
collection, the system will then try to expand the middleware heap using 
the standard policy based on 30% free space, or the minimum expansion value 
of O.S Mbyte if the 30% expanaion would exceed the midpoint. In Other 
2 5 words, the policy is to try to prevent the middleware heap from expanding 

past midpoint 5S5 (although this may happen eventually if the garbage 
collection does not reclaim sufrlcient space) . The rationale behind this is 
to try to avoid taking up space from the transient heap, a particular 
concern being the possibility of a long-lived middleware ob3ect becoming 
10 pinned high up (in the sense of Figure S) in the heap storage 560, and 

therefore seriously limiting the amount of space available to the transient 
heap . 



35 



40 



considering now the transient heap, then once this reaches (or would 
reach) the midpoint 565, then again the expansion rate for this heap is 
reduced to half the minimum expansion value. However, unli)ce ror the 
middleware heap, this expansion is allowed to continue on past the 
midpoint, until eventually all usably heap space is exhausted, when clearly 
a garbage collection will be needed. The motivation here is that it is 
expected that most new objects for the transaction will be created on the 
transient heap, so that this requires most room. Moreover, since the 
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transient heap will be deleted anyway at the conclusion of the transaction, 
the concern about pinned objects is reduced (or the JVM will become dirty, 
as discussed in more detail b«low) . a further corx==quence o£ this is that 
there is a general desire for performance reasons if possible to avoid a 
5 garbage collection during a transaction, but rather to po=tpone this if 

possible uncil the heap refresh (step 445, see Figure 4) performed as part 
of the JVM reset. 

With reference to step 765 in Figure 7 (shrinking the other heap to 
10 reclaim space) . this step i« «ot pe^ficrmed £or ^ alloo^tion request to ttie 

crara=xcr.c heap (in other words, a No from step 755 would go straight to 
Error 780) . However, it will be noted that if the allocation request is 
^ouc to fail, tho he*p would already have been garbage collected and 
compacted, and the size of the heaps shrunk as per the policy di^cuaaed 
above, so that the amount of free space available to reclaim anyway is very 
limited. However, step 765 in Figure 7 is performed for an allocation 
request to the middleware heap, ixa ord^r to cry to reclaim 3pac= f^om the 
trar.=ionc he^p . The errect of tills, if successfuly, would generally be to 
reduce the transient heap below its original size. 



IS 



20 



3S 



AS one minor subtlety on the above, in the preferred embodiment, the 
midpoint position, recalculated when tho middl«w»^e heap is shrunK {but 
not wnen the transient heap sise is altered, or when che middleware heap is 
enlarged) , the new position being halfway between the current middleware 
heap boundary and Che current transient heap boundary . Thi s attempts to 
provide some tuning of the space allocation between the two heaps, although 
m^y other algorithms co».ld be considered as tne basis Tor the control 
procedure . 



30 



one complication that arises from effectively having multiple heaps 
of various sizes is that it becomes more complex to determine whether or 
not a given object reference is within a heap (as required, for example, 
for step 612 Of Figure 6A> . and if so which one (in case, for e3«n,pi*, they 
have diff«r^„t g^rb^ge collection polici==) . one possibility is to compare 
the reference with the information in the heap control block 530 (see 
Figure 5) . However, with multiple he^.pg, ^nd ^.Iso a system heap which is 
not necessarily contiguous, this becomes a time-consuming operation. 

In order to overcome chi= problem, the preferred embodiment adopts 
the approach illustrated schematically in Figure 8. As shown, system 
address space or vircusl memory boo is split into chunks of a standard 
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size, referred to herein as slices 802. As previously mentioned, in the 
preferred embodiment on a 32 bit system, these slices are each gAKSytes in 
size. Th« slices can be r^umbercd linearly as shown wich increasing address 
space. The heaps can then be allocated out of these slices, in such a way 
that heap space is always allocated or deallocated in terms of « integral 
number of slices. Figure a snows three different heaps (for simplicity 
termed A , B and C) , whereby heap A is non- contiguous ^nd comprie^a sliccc 
3-4 an<s 6-7, heap B comprises slice s, and heap c is contiguous and 
comprises slices 12-14 inclusive. Note that two or more of these heaps may 
possibly be being m^n^cged a« single blook of etoreige (ie in The same manner 
CO rne transient and middleware heaps of Figure 5) . 
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Also illustrated in Figure 8 is lookup table 825, which has two 
columns, the first 830 representing slice number, and the second 83i 
representing heap number. Thus each row of the table can be used to 
aetermine. for the relevant slice, which heap it is in - a value of 
(indicated Toy a dash) is -resumed to indicate that the slice is not 
currently in a heap. The system updates table 825 whenever slices are 
allocated to or deallocated from the heap. 

Using table 825 it now becomes very quick to determine whethe:r ^ 
given m^n,o>ry ^d<i^,s6 is in a ho=.p . Thu« initial determination is made of 
the relevant slice, by dividing the given memory location (minus the system 
base memory location if non-zero) by the slice siae, and rounding down to 
the next integer (ie truncating) to obtain the slice number. This can then 
be uced to directly access Che corresponding heap identifier in column 83X. 
In fact, it will be appreciated that column 830 of Table 825 does not need 
to be stored explicitly, since the memory location of each entry in column 
831 is simply a linear function of elico number. More specifically, each 
entry in column 831 can typically be represented by l byte, and so the 
information for slice N can be found ^.c the ba=e location for tabic S25, 
plus N bytes. Overall therefore, this approach provides a rapid mapping' 
from object location to heap identity (if any) . irrespective o£ the number 
of heaps, or the complexity of their configuration. 

One problem however with the t«chni<jue illuetratcd in Figure 8 is 
that on bit macnines. the virtual memory or address space is so great 
that table 825 would become prohibitively large. Thus in a preferred 
embodiment for auch systems, a modified mapping Is used, as shown in Figure 
9, which has an extra layer in the memory mapping arrangement. In the 
diagram, memory 900 reprosente the =y3tcm addre== =pace or virtual memory. 
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whicn as in Figure 8 is divided into slices 902 (the difference from Figure 
8 being that on a 64 bit system, address space is much larger, so chere are 
many more slices) - Figure 9 illustrates the location of two heaps, 
arbitrarily denoted A and B, with A comprising slices 2-4 inclusive, and B 
5 comprising slices 1026-1028 inclusive and also slices 9723-9726 inclusive. 

Also shown in Figure 9 are two lookup tables, 925, 926, each of 
which, for- the sake of illustration, contains 2048 entries, and maps to a 
corresponding range or slices in adaress space 90a. Thus lookup table 925 
10 maps slices 0-2047, whilst lookup table 926 maps slices 8192 - 10239 . These 

lookup tables are directly analogous to chac of Figure 8, in chac chey 
logically contain two columns, the first 920 identifying a slice number, 
amd the cecaona 921 the identity o£ any heap within that slice (oar else 

zero) . Tables 925 and 926 can be regarded as forming the lower level of the 
15 lookup hierarchy. 

Figure 9 also depicts a higher layer in the lookup hierarchy, namely 
tabic 940, which again logically containo cwo columnc , The firct column 941 
logically represents the number of lookup table 92 5, 926 in the next lower 
layer o£ the lookup hiexax-chy , whilsst the aecond column contains: 3. 

pointer to the relevant lookup table. Thus the first row of column 942 
contains a pointer 951 to table 925, and the fifth row of column 942 

concains a poincer co cable 926 . 

2 5 It will be noted that to conserve space, lookup tables in the lower- 

level of the hierarchy only exist where at least some of the corresponding 
slices are assigned to a heap. Thus for the particular arrangement of 
Figure 3, the looJcup cables for slices 2048-4095, 4096-6143, and 6144-S191 
have not been created, since none of these slices has been assigned to any 

30 heap. In other words, lookup teibles ^25, 926, etc for various slice ranges 

will be created and deleted according to whether any slices within that 
slice range are being utilised for the heap. If this is not the case, and 
the lookup table is deleted (or not created in the first place) , the 
pointer in column 942 of top level lookup table 940 is set to zero. 

3B 

The operation of the embodiment shown in Figure 9 is analogous to 
that of Pigu.2re Q, e^ccept that ther^ is an extra level of -itKiireacion 
involved in the hierarchy. Thus to determine whether a particular reference 
02: address is within a heap, the correct row is determined based on a 
40 knowledge of the BXze or a slice 902, ana also the number of rows in each 

lower level lookup table 925, 926. It is expected that for most rows, the 
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corresponding- entry in column 942 will be null or zero, immediately 
indicacing that that address is not in a heap slice. However, if the lookup 

select*: A r-ow wKieH Has non-zearo entary^ cHxc i,& then followed (using 

pointer 951, 952 or equivalent) to the corresponding lookup table. The 
desired entry is then found by locating the row using the reference linder 
invcstigacion fallowing for which particular lookup cable is involved) , and 
examining the entry for that row in column 931. This will indicate directly 
wHechor or not the slice containing the referenced location is in a tieap, 
and if so, which one. 

As an example of this, to inveccig-ate memory address ^37405384 w© 
rirsc integer divide by 65536 (the size of a slice in the preferred 
embodiment), to give 9727 (truncated), implying we are in slice 9727_ Next 
we perform an inceger division of 9727 by 2048 (Che number Of entries in 
each lower level look-up cable) , to give 4 (truncated) , implying we are in 
15 the 5ch row of column 941. It will be appreciated that we could have got 

here directly by dividing 637405384 by 134217728 (which equals 2048x65536, 
or in other words, the total number of addresses per lower l^ivel lookiap 
table). In any event, from tne 5Ch row of table 940, it is determined that 
the corresponding entry in column 941 is non-zero, so chat the specified 
20 address may poesilaly lie in a heap. Accordingly, pointer is followed tO 

table 926. Here we can determine that the row of interest is number 1535 
(equal Co 9727 modiilo 3048) . from which we can see that this particular 
slice is not, after all, part of heap. It follows of course that this is 
also true for any address within this slice. 

25 

Note that as for Figure 8, the slice number columns 93 0 of lookup 
taJbloc 925, 926" are not in practice needed, since the desired row in column 
931 can be determined directly by using the slice number (modulo 2048) as 
an offset from the base addres:*: of ch*9 lookup table. L±Jc«wie«, column 941 
3 0 Of table 940 is also redundant, since the relevant row can be determined 

directly from the address. In fact however, the vast majority of rows in 
table 940 {column 940) are likely to be zero, in which case storing the 
information in some other data structure such as a linked list would be 
much more efficient in terms of space (laut may reduce lookup speed) . 



35 



40 



It will be appreciated that einy suitable data structure c^ uj5«d 
for storing -the two levels or lookup information, snown as tables 940, ajid 
925, 926 respectively. It will also be recognised that the sizes discussed 
with reference to Figures 8 and 9 (a slice size of 65536 bytes; 2048 slices 
per lower level lookup table) are exemplary only, and can be varied as 
circumstances: dict;it<a to optimize performance. 
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ReTLuming now to Figure 4, as previously aescrit)eay ac ctie enC oC a 
crsLnsacnion th.e nransient bieap is deleted (equivalent to the refresh heap 
step 445. performed as part of the reset JVM). This activity is generally 
similar to garbage collection, although certain optimizations are possible, 
and certain additional constraints need to be considered. Thisj procefi:^: is? 
shown in more denali in cne now chart of Figure lO (which is split for 
convenience into two components, lOA and lOB) , The first step in Figure lOA 
(10 05) is to wait for all f inalizat ion activity to complete. Thus if there 
has been a GC during a transaction then there may be f inalizers to be run 
smd they must be arun before cine carancienc heap can be reset, as the 
f inalizers could create (or require) other objects. This checking is 
performed by confirming that the reference handler and final izer thread 
have emptied their respective queues, and chat there are no other 
^5 in- progress objects (ie the processing of all pending finalization objects 

Jnae been completed) . Next all the locks required for garbag-e collection are 
obtained, and all other threads are suspended (step 1010) . The system is 
now in a position to commence deletion of the transient heap. 

20 In order co accomplish this, the stacks and registers of all threads 

are scanned (as for a normal garbage collection) , and if a reference is 
found to the traoisient heap (step 1015) then the JVM is potentially dirty 
and so cannot be reset. The reason for this as discussed in relation to 
Standard garbage collection (Figure 6) is that the references on the stacks 
emd registers must be treated as live, even though it xsz not certain chat 
they are in fact olsject references. To Tirm up on this the references are 
tested to see if it is possible to exclude them from being object 
references (step 1020) , essentially lay using the same three tests 612, 615 
and 620 of Figure 6. In other words, if the possible reference is not on 
the heap, oir doco not fall on an 8-byte boundary, or does not correspondl to 
an allocated memory location, then ic camnot in fact be a reference. 
Otherwise, the register or stack value may still be a reference, and so 
processing has no exit with em error that tne *JVM is dirty and cannot be 
reset (step 1099) . Note that references from the stacks or registers to the 
3 5 middleware or system heap are of course acceptable, because objects on 

these heaps are not being deleted. 

It will be appreciated that based on the above, a spurious data value 
in a stack or register will sometimes prevent JVM reset. However this 
40 happens relatively infrequently in practice, because all but the main 

application thread and certain system threads should have terminated at 



25 
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this point, so the stacks are relatively empty (nb the policy adopted in 
the preferred embodiment is that a JVM cannot be reset if more than a 
single tra.nsa.ct ion thre^id was used; multiple middleware thzreads a.re 
tolerated providing they have terminated by the completion of the 
5 middleware tidyups) . Related to this, as previously mentioned finalizer 

objects on the transient heap are retalnea in that: heap until a JVM reset. 
This meajis that references to such objects are not entered onto the stack 
foar th^ fina-lizer threa-di which would otherwise typically cause the reset 
to fail at steps 1015 and 1020 (this would be the case even where the 
10 finalize method for the object had been finished, cine-? this would not 

necessarily lead to complete deletion of the corresponding stack entry; 
rather the finalizer thread may enter a function to wait for more work, 
resulting in uninitialised areas on the stack which may point CO previously 
processed finalizer objects) . 

11 

It Is important to note that error 1099 indicating that the JVM is 
dirty does not imply that previous processing was incorrect, merely that 
tine ovM cannot be reset (althougn of course chis may in turn indicate some 
unexpected action by the application) , In other words, a new JVM will need 
to be Gar<aa.tod for the next application. Because o£ this, if it is aetected 
that the JVM is dirty, such as a negative outcome at step 1020, the method 
normally proceeds immediately to JSt^^p 1099. This retuma an err-or code to 
the reset jvm request rrom the middleware, with no attempt to continue to 
perform ajiy further garbage collection. The reason for this is that the 
2S middleware may wont to do a little more tidying up, iDUt generally It IS 

expected that it will terminate the current JVM fairly quickly. Hence there 
is iinlikely to be a need for amy further garbage collection, which ratiier 
would represent an unnecessary waste of time, A similar policy is adopted 
whenever the processing of Figure lOA indicjut^e that the JVM is dirty. 

30 

Assuming now a negative result from step 1015 or 1020, the JVM 
refresh continues with an examination of the primordial statics fields 
(step 1025) to see what objects they reference. Since these fields will be 
retained through ch^ jvm reset, it ic importstjit that the objects chat they 

3 5 reference, either directly or indirectly, are likewise retained. If however 

the referenced objects are application objects ftested at step 1030) ch^n 
clc^a3rly these cannot be retained, because tne- application tias essentially 
terminated, and the purpose of resetting the JVM is to allow a new 
applic^a-tion to comraenca . Therefore, if the primordio-l ©cacics do reference 

40 an application object, then the JVM is marked as dirty, and the method 

proceeds to error 1099- 
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Assuming chat the objects referenced by the primordial static fields 
are noc application objects (typically they will be px-imoardiAl object 

inscances or arrays), chen these are moved { '^promoted" ) from che transient 

5 hesip to tho middleware heap (ec^p 1035) . The reason why such objects are 

placed on che transient heap initially is that at allocanion time, ic may 

not be known that the object: to be allocated is a primordial static 
variable, or reachable rrom one. 

10 (Note that thic approach beara some cimilaarit ies to g^ne^aratiori^il 

garbage collection, in which new objects are initially allocated to a 
short-term heap, and then promoted to a longer-term heap if they survive 
beyond a certain time, but che cricerion for promotion is ciiffer-enc: 
essentially it is based on object type or usage, rather thaja age. 

15 Generational garbage collection is discussed further in the book by Jones 

and Lin referenced above) - 

One complication {nor. shcrvn in Figure XO) is that promoting an object 
from the transient heap to the middleware heap may lead to an allocation 
2 0 failure on che middleware heap ir space is exhausted . Xn such an 

eventuality, a garbage collection is performed. If this still does noc 
create cnovAgh space, ch.cn this will lead to error 1099, 

A^ftear the primordi^*.! sc^itic objects have been promoted, the next step 
25 is CO review the card table (536 - see Figure 5) . The card cable represents 

a set of bytes, one per fixed unit of heap (for example 512 bytes) . 
whenever an object reierence is written to the heap, the card cable is 
updated co indicate dirty (nb marking a card as dircy does not imply thac 
the iTVM itnclf ie necessarily dirty) , The card updated corre<5pondc not to 
30 the portion of the heap which contains the updated object reference itseir, 

but rather to tjie portion of heap which contains che cop of the object that 
includes the the reference (for a small object these may of course be che 
same) . Given that updating object references is a frequent operation, the 
card cable muse operate very cjuickly. This is the rcacon why each card is a 
35 byte despice containing only a single bit of information, because in 

paractice this can be manipulated more <3xiickly- Purthermore , no accempt at 
this write stage is made to investigate the nature or the reference upaate, 
for example whether che reference was set to a null value/ or to an object 
in a particular heap. 

40 
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Now during JVM reset the card table is scanned, or more particularly 
those cards which correspond to the region currently assigned to the 
middleware heap ar-e s:c.5Lnn«d. Thus ca.r-dfi for the tr-ajnsient hccip 520 and for 
the Unas signed region 510 are not scanned, even if they have previously 
5 been part of the middleware heap. As part of this review, it is first 

determined whether any cards are set (ie marked as dirty) (step 1045) . This 
indicates that a reference in the corresponding portion of the middleware 
h«ssip has been updated since the laist JVM react, and so must be checked to 
confirm that it does not point to the transient heap. The first part of 

10 this check is to find all object re£«^r^nces in object b which eta.rt in cbe 

hcsap portion corresponding to the marked card. Note that there may be more 
than one object to review here, or possibly none at all if the object 
preiriously loccxtcd there has since been garbage collected and the space 
reused by a larger object whose beginning is situated outside that portion 

15 of the heap. Fov all objects associated with a marked card, all references 

contained in those objects {even if the references themselves are outside 
the portion of the heap corresponding to the c^^rd) are checked to see i£ 
tKcy point to cbe transient heap (step 105 0) . If they do not, for exan^le 
they contain only null pointers, and/or references to the middleware heap^ 

20 tben this is not a. problem for OVM reset. On the other hand, it there are 

any such pointers to the transient heap from the middleware heap, this will 

be a problem on reset »inc^ thoe^ references will no longer be valid once 
the transient heap is cleared. The one exception to this is where the 
objects containing these problematic references are no longer live (i© 
2 5 covAld be garbage collected) , 

Therefore/ on a positive outcome to Step 105 0^ Che system performs 
the mark phase of a garbage collection (step 1055} , which is a relatively 
long operation. If the problematic r<?forences are in objects which ctrc 
30 marked (ie live), as tested at step 1060, then they are indeed problematic, 

so the OVM must be regarded as dirty; hence the method proceedi? ro ^rror 
1099- On the other hand, if the problematic references are in objects which 
are not marked, then they can effectively be ignored, since these objects 
are no longer live . 

35 

Note that if the heaps have been compacted during a transaction, then 
this invalidates the card table, in such cases a full scan of the 
middleware heap is required to locate an object references to the transient 
hejip, equivalent to the garbage collection mark phase of step 1055 if any 
4 0 such references are foiind. 
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Assuming that the test of seep 1060 produces a negative output (ie no 
live middleware references to the transient heap) , the method proceeds to 
scan JNI global references. These are references which are used by native 
code routines (ie running directly on OS 30 rather than on JVM 40, see 
Figure 1) to refer- to Java, objects. Using the Java Native Interface (JNI) 
such rererences can be made global, that is available to all threads, in 
which case they will exist independently of the thread that createa them. 
All such JNi global reference slots are scanned (step 1065) (see Figure 
lOB) and if a reference to the transient heap is found (step 1070) the JVM 
is marked as dirty (ic error 10 99) , since these references will clearly 
tail once the transient heap is reset. 



Providing this is not the case, the Jni weak references are scanned 
next (step 1072) . These are references wHich th« application opacifies 
15 using JNI as expendable, in that they can be deleted if no longer used. 

According, any such weak JNI references to the transient heap that are 
found can be nulled (etep 1074), thereby permitting the JVM reset to 
proceea . 

"'===^' static variables of all middleware classes are scanned 

(step 1076) to see if any directly reference the transient heap {*t=p 
1078). Note that theae won- t previously have been examined, since they are 
on the system heap rather than the middleware heap. If a direct reference 
to the transient heap ic foxind. the JVM is dirty, corresponding to error 
25 1099. <Note that unlike for the primordial statics (step 1025) there is no 

need to iteratively follow references from the middleware statics, since 
any indirect references will already have been picked up by preceding 
analysis) . If no transient heap references are found, the proceseing 
continues to step 1080 in which Objects on the transient heap are reviewed 
30 to see if any have finalizer methods., and any that are found ;ar^ now run 

(step 1082) . one important aspect o£ the preferred emCOdiment is that these 
finalizer methods are run on the main thread, rather than being passed to 
the system finalizer. An implication of this is that the finalizer methods 
will bo ruxx in the known and controllable context of the main thread. In 
3 5 addition, ic is ensured that the finalizer methods complete before 

progressing to the next stage of th= OVM reset, unrortunately . finalizer 
methods can create fresh objects, which may newly reference the transient 
heap. Therefore, after the finalizer mcthodc have conipleced. processing 
mu3t return to Step 1025 to repeat much of the checking, to ensure that the 
'0 system is still in a position for JVM reset. In theory, if the finalizer 

methods have created new objects on the transient heap which themselves 
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have f inalizer methods: Chen this loop may have to be followed more than 
once , 

Note chat strictly speaking there is no formal requirement to run the 
5 f in^xldLzersi ait this scage, since chis is the DOinc at which the JVM would 

normally terminace ac che conclusion of an application. racher than ha-^ing 
a garbage collection performed. Nevertheless, the policy in the preferred 
embodimcTit is tha.t object finalisers will be inxci befoare deletion sit JVM 
reset, although other imp lemencac ions may have different policies. 

10 It ic accumed thac ^v*5inti\ija.lly all finalizers will be run, resulting 

in a negative outcome co the test or seep xoso. in chese circumscances , chc 
method proceeds Co step 1085, which represents reset of the JVM by deleting 
the cransienc heap, in praccicc, this involves scvciral operacions. Firstly, 
if Che mark phase of Che garbage collection was run (step 1055} then che 

15 sweep phase, which is relatively quick, is now run on the middleware heap. 

Next, various operations are performed to formally reset the transienc 
heap, including: the removsLl of all transient heap monitors and the freeing 
of storage for transient neap class blocks (ie releasing che stoir&gc 
ucilised by the class block, which is not on the heap) . The transient heap 

2 0 pointers can now be reset so that che heap is effectively emptied, and 

restored to its initial size (by setting boundary 522 appropriately) , 

In the preferred embodiment ic is declared Chac cne nranslenu heap 
will be set to the same initial size for each transaction. One potential 

2 5 problem with honouring chis is Chac Che middleware heap may have e^cpanded 

during the previous application, an:d then retain this space through a reset 
of che JVM- since there is no constrainc on the tra^nsient heap shrinking 
below its initial size, to surrender space to the middleware heap if 
required, thic can in turn make it impossible for the transient heap in the 

3 0 next incarnation of the JVM to be set to che same ininial size as che 

current transient heap. If this problem arises, a specific attempt is made 
to shrink the middleware heap sufficiently to accommodate the correct 
initial size of the transient heap. However, if this attempt is 
unsuccessful, Che JVM must be marked as dirty, an<i cannot be r^^S'SC to its 
35 initial state. 

Once the transient heap has been recreaced (although it could be done 
before) , a garbage collection is performed on the middleware heap if 
eicher of che following Cwo cases ic true: firstly, i£ che number of 
40 slices left in the unallocated portion of the heap^ between the middleware 

heap and the transient heap, ia l^ss ch;aji two, or secondly if the amount of 
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free space in the middleware heap plus half the unassigned portion 515 of 
the heap (see Figure 5) is less than Che amount of storage used by the 
previous crancaction times three . Both of chese can be regarded as a 
preemptive garbage collection, performing this operation now if the next 
5 transaction Ltz otH^^rwise likely to be cone trained for space, in the hope 

rtiac this will avoid a garbage collection during the transaction itself. 
Note that in the current implementation this preemptive garbage collection 
would be performed Irrespective of whenner a garbage collection mark phase 
was performed in step 1055. Finally, all the threads can be restarted and 
10 the garbage collection locks released, whereupon the reset is completea, 

and the JVM is available to support the next application. 

The skillea person will be aware of many possible variations on the 
embodiment described above. The invention has been deccrib^a primarily in 

15 relation to Java in a server environment, but it will be understood that it 

applies to any other language with similar properties (possibly CU from 
Microjsoft Coirporation) , and is aleo potentially applicable to the Client 
embodiment, such as when it is necessary to have a quick start-up of 
applications- In addition, many of Che detailc of the syetemo and processes 

2 0 utilised are exemplary only, and can be varied according to particular 

circumstances. Thus other modifications to the embodiments described herein 
will be apparent co the skillea person yet remain witliin the scope of the 
invention as set out in the attached claims. 

25 
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CIiAIMS 

1. A computer system providing an object-based environment, said 
computer system including storage, a contiguous linear portion of which is 

5 logically divided into first and second heaps located at opposite ends of 

the stor-age portion, with any gap between the two heaps representing an 
unallocated region of storage, wherein references are permitted from 
objects on the first heap to objects on the second heap and vice versa, 
said system comprising: 
10 a garbage collector for operating across both heaps to remove objects 

Chat are no longer live; 

means for expanding the first heap into said unallocated region 
accoarding to a. first oxpcinsion policy; and 

means for expanding the second heap into said unallocated region 
15 according to a second expansion policy. 

2. The computer system of claim i, wherein said contputer system supports 

a transaction processing environment,, and said fix's t heap ±5 used for 
storing objects that are deleted at the end of the current transaction^ and 
2 0 said second heap is used for storing objects that persist from one 

transaction to another. 

3- The computer system of claim 2, wherein the first heap is reset to 
the same predetermined initial size at the start of each transaction. 

25 

4. The computer system of claim 3, wherein the system returns an error 
condition if the second heap has expanded such that it is not possible to 
reset the first heap to its predetermined initial size. 

30 5, THe computer system ot claim 3, wherein a midpoint is aerined halfway 

between the first heap and second heap, when they each have their initial 



€. The computer system of claim 5, whcir^^in the first eacpiu^^ion policy ic 

3 5 always to expand into said unallocated region in order to satisfy a storage 

request . 

7. The computer system of claim 6, in which the rate of expansion of the 
first heap into the lorxallocated arcgion is slower once the first heap has 

4 0 passed said midpoint. 



Received 06-11-00 15:32 



From-01962 818927 



To-THE PATENT OFFICE 



Page 47 



I 



30 



35 



GB92 0 00OlOOCtBl ^1 



8. The computer system of claim 5, wherein the second expansion policy 

is to expand into said unallocated region in order to satisfy a storage 
trecjuesc until said midpoint is reached, whereupon said system 
preferentially performs a garbage colleccion to satisfy said r^gviest. 

5 

3. The computer system of claim 8, wherein the second expansion policy 
further includes trying to shrink the first heap to allow room co expand 
said ttccond heap in order to satisfy a storage request. 

computer system a£ claim 1, wherein said garbage collector 
performs a compact operation after a garbage collection of the first and 
second heaps, said compact operation being performed in response Co a first 
set of criceria relevant to the first heap, and a second set of criteria 
relevant to the second heap. 

IS 

11. The computer system of claim 10, where said second of criteria 
are more seneitivs to f aragcmcntation than the first set of criteria, 

12. The computer system of claim 10, further including means for 

2 0 shrinking che Hirst and second heaps after compaction, and returning 

released storage to said unallocated region. 

la. The compucer system o£ claim 1, Curther including a bit array, having 
one bit for each possible object location in said portion of storage, ^:aid 
2 5 bit indicating whetH^r or not there ic cm object currently scored at the 

corresponding object location. 

1^. A method of operating a computer system providing an object-based 
environment, said computer system including storage, a contiguous linear 
portion of wiiich is logiccilly divided into first and second heaps located 
at opposite ends of the storage portion, with any gap between the two heapi= 
representing an unallocated region of storage, wherein references are 
permitted rrom objects on the first heap to objects on the second heap and 
vice versa, said method comprising the steps of: 

operating a garbage collector across both heaps to remove objects 
that are no longer live ; 

e^cpandir^g the first heap into said unallocated region according to a 
first expansion policy; and 

for e^qpanding the second heap into said unallocated region according 
to CL second expansion policy. 
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15. The method of claim 14, wherein said computer system supports a 
transaction processing environment, and said first heap is used for storing 
objeccc chat a-ire deleted a.t the end o£ the cue-rent tri»jaG action., ^^.tidl s??».lci 
second heap is used for storing objects that persist from one transaction 

5 to another - 

16. The method of claim 15, wherein the first heap is reset to the same 

predetermined initial cise ar. Che ecart of each transaction. 

10 17. The method of claim 16, wherein the system returns a.n error condition 

if the second heap has expanded such that it is not possible to reset tiie 
first heap to its predetermined initial size. 

18. The method of claim 16, wherein a midpoint is defined halfway between 
15 the first i.ieap and second heap, when they each have their initial size. 

19- The method of claim IS, wherein the first expansion policy is always 
to expand into said unallocated region in order to satisfy a sv;orage 
request . 

20 

20. The method of claim 19, in which the rate of expauision of the first 

heap into the unallocated region is slower once the first heap has passed 
said midpoint . 

25 21. The method of claim is, wnerein the second expansion policy is to 

expand into said unallocated region in order to satisfy a storage request 
until scLid midpoint is reached, whereupon cciid cyotem preferentially 
performs a garbage collection to satisfy said request. 

3 0 22. The method of claim 21, wherein the second expansion policy further 

includes trying to shrink the first heap to allow room to expand said 
second heap in order to satisfy a storage request, 

23. The method of claim 14, wherein said garbage collector performs a 
3 5 compact operation after a garbage collection of the first and second heaps, 

said compact operation being performed in response to a first set of 
criteria relevant to the first heap, aind a second— set ot criteria relevant 
to the second heap . 

40 24. The method of claim 23, where said second set of criteria are more 

cencitxve to f ra.gem€nta.t ion thatn the first set of criteriei . 
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25. The method of claim 23, further including the step of shrinking the 
first and second heaps after compaction, and returning released storage to 
said unallocated region, 

26. The metKod. o£ clsLim 14, fusTther* including ^He s^ep o£ psrovidinc^ a. l^ic 

array, having one bit for each possible object location in said portion of 
STiorage, said bic indicating whether or not there is an object currently 
stored at the corresponding object location. 

27. A computer program for implementing the method of airiy of claims 14 co 
26. 
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A COMPUTER SYSTEM WITS TWO HEAPS IK CONTIOTOUS STORAGE 



ABSTRACT 



5 A computer system provides an object-based environment. Ttie computer 

system includes storage. A contiguous linear portion of the storage is 
logically divided into first and second heap« loc^^ced at oppocito ends of 
Che linear portion ot storage. Any gap between the two heaps represents an 
unallocated region of storage. The system permits references from objects 

10 on the firat heap to objects on the second heap and vice Versa. A garbage 

collector operates across both heaps to remove objects that are no longer 
live. Means are provided for expanding the first and second heaps into the 
unallocated region. The first heap is expanded according to a first 
expansion policy, and the second heap is expanded according to a second 

15 expansion policy. 
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